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(57) ABSTRACT 

The present invention involves a method for multicast file 
distribution and synchronization in data networks. 
Specifically, the present invention includes a mechanism for 
efiScient and reliable distribution of a data file from a single 
source to a large number of receivers using multicast dis- 
tribution in wide area networks. The multicast file distribu- 
tion is done by designating a receiver as an active receiver. 
The active receiver is selected using a novel token granting 
procedure. Once selected, the active receiver is responsible 
for generating retransmission requests as well as providing 
How control feedback to the server during data transfer. All 
receivers on the network are offered a chance to become an 
active receiver in a controlled manner, and only one receiver 
can be an active receiver at any given time. This process 
continues until there are no receivers in the group with 
missing data segments. The second part of the protocol 
provides synchronization of the file version to ensure that all 
receivers have the last distributed version of the data file. In 
addition, the protocol allows newly joined receivers to 
request the file from the server. The protocol is suitable for 
applications where a server periodically distributes a new 
version of the data file to receivers in the network. In 
addition, the protocol can be deployed with or without the 
support of Internet Protocol (IP) multicast technology, and is 
not tied to any particular network topology or transmission 
medium ./C 
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METHOD OF MULTICAST FILE ensuring end-to-end reliability. The two popular approaches 

DISTRIBUTION AND SYNCHRONIZATION proposed to date are called sender-initiated and receiver- 
initiated. In the sender-initiated approach, the sender main- 

HELD OF THE INVENTION tains the state information of all of the receiving clients. 

rj... .. , . . .u J r 1.- . CI J- . • 5 Here, the sender updates the state information as each 

This invenuon relates to methods of multicast file distri- ^^^^^ ^^-^^^ ^„ acknowledgment of the received 
button aiid file synchrontzation in computer networks. More ^ack to the sender. Each time the sender distributes 
specifically the present invention provides a low-overhead ^j^j^^ transmission is in the form of a multicast trans- 
method for distributing data to a target group of devices or ^^^^^ receivers. Each time a receiver 
nodes in a computer network and ensures that all members ^^j^j^^ ^ 3^^^,^ ^^^^ acknowledgment by a 
of the target group mcludwg new members of the group are j^^j^.^^, transmission to the sender. In contrast, in the 
kept consistent with respect to the distributed data. receiver-initiated approach, each receiver sends a negative 
BACKGROUND OF THE INVENTION acknowledgmeot (NACK) message to the sender if it fails to 

receive a data packet. The NACK informs the sender if a 

Certain computer applications require reliable distribution data packet is missing or if the transmission errors. Here, the 

of a single large file to a large set of receiving hosts. As sender multicasts all packets, giving priority to 

known in the art, file distribution can be managed by either retransmissions, and a receiver sends a NACK message each 

a multicast or unicast transmission. When dealing with a time it detects an error or a lost packet, 

large number of receivers, the use of unicast protocols such sj^ce there are multiple receivers in a multicast 

as TCP is inefficient as it requires the sender to separately transmission, the sender-initiated approach needs to have 

transmit data once to each target. Conversely, multicast one control box of state information per receiver. The sender 

sends data to a large number of receiving hosts m one j^ust also find the proper control box and update the state 

simultaneous transmission. In a multicast transmission, the information for each received acknowledgment message. In 

sender only transmits each data packet one time and an contrast, in the receiver-initiated approach, the retransmis- 

underlying multicast deUvery mechanism efiSciently delivers ^5 sion task is distributed to all receivers, as the sender keeps 

each packet to all of the targeted receivers. Thus, when ^o stale information on each receiver. Here, the sender 

dealing with a large number of receivmg hosts, a multicast sjj^piy responds to data requests each time a NACK is 

protocol is more desirable. However, the use of a multicast received. From this perspective, receiver- initiated protocols 

distribution requires additional mechanisms to ensure that ^re far more scaleable than sender-initiated protocols, 

all group members receive the complete set of data seg- g^^^^^, ^^^^^^^ ^^^^^ ^^e art disclose designs to 

menls In addition, other complications arise with these reliability of multicast transport protocols that can 

reliability mechanisms as they are applied to different mul- handle one-to-many and many-to-many node distributions, 

ticast transport protocols. ^^^^ ^^^^ protocols are based on the receiver- initiated 

One method that has been used to increase the reliability multicast paradigm and they generally follow the model of 
of data transmissions involves the use of unicast protocols. 35 multiple receivers sending NACK's to one sender. Because 
In unicast protocols, such as TCP, the sender achieves receivers communicate NACK's back to the sender, receiver 
reliability by requesting acknowledgments for the data seg- initiated protocols have the possibility of experiencing a 
ments from the receiver. This model is not suitable for NACK-implosion problem if many receivers detect trans- 
multicast distribution because the sender may become mission errors. To avoid this problem, receivers use a NACK 
flooded with acknowledgments if every receiver sends an suppression scheme. Whenever a receiver detects a packet 
acknowledgment to the sender. This is known in the art as joss, it waits for a random time interval and then multicasts 
the acknowledgment (ACK) implosion problem. The use of a NACK to the sender and all other receivers. When a 
this model in a multicast protocol presents an inefiGcient receiver obtains a NACK for a packet that it has not received 
process that wastes a significant amount of network band- and for which it has started a timer to send a NACK, the 
width. Hence, the primary goal in the design of reliable 45 receiver sets the timer and be haves as if it has sent a NACK. 
multicast protocols involves the goal of avoiding multiple expiration of a timer without the reception of the 
acknowledgments from the receivers and managing these corresponding packet is the signal used to detect a lost 
acknowledgments in an efficient way. packet. The goal of this scheme is to only send one NACK 

ReUable broadcast protocols have existed for quite some back to the source for a lost transmission for the entire group 

time. These protocols rely on the broadcast nature of the 50 of receivers. 

underlying network such as ethemet on local area network in other prior art, this basic NACK suppression mecha- 
segments. However, techniques for reliable multicast trans- nism has been slightly modified. For example, some proto- 
missions over wide area networks (WAN's) are just emerg- cols require receivers to send repair requests to the original 
ing. One of the primary reasons that there is no established sender and other nodes prescribe one or more special 
standard for reliable multicast is that different multicast 55 retransmission nodes and arrange them in a tree hierarchy, 
applications have different requirements for transport pro- The introduction of the tree hierarchy only achieves scal- 
tocols. For example, the requirements of non-interactive ability but it doesn't solve the basic problems with the 
applications such as group distribution of a large file or data algorithm. Theses NACK avoidance algorithms were 
set has different requirements than interactive counterparts. designed for a limited size network, such as LAN or a 
Typically, non -interactive appUcations can tolerate much 60 network with a small number of Internet nodes. This is 
longer latencies, accept out of sequence packets, and may because the basic NACK- avoidance algorithm requires that 
even tolerate extreme fluctuations in network throughput. In timers be set based on update requests generated by every 
contrast, interactive multicast appUcations may tolerate node. As the number of nodes increases, the work load for 
some unreliability, but they have tighter performance each node increases at an exponential rate. Even worse, 
bounds on latencies and network throughput. 55 nodes that are on congested networks may constantly inter- 
Designs for multicast transport protocols can be charac- fere with the rest of multicast group by multicasting a large 
terized depending upon the node that is rCvSponsible for number of NACK's, 
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The requiremeot of multicast transmissions of NACK number of receivers using a novel method based on the 

messages by all receivers to avoid NACK implosion is a selection of an active receiver. The active receiver selection 

major limitation of the prior art. These methods not only is done using a novel token granting mechanism. In addition, 

require the sender to have a multicast packet forwarding the protocol introduces methods for eflScicntly transmitting 

tree, but there should also be a forwarding tree at each 5 and retransmitting data segments. The active receiver is 

receiver to multicast packets to other members. In addition, responsible for providing flow control feedback to the server 

this NACK suppression scheme has increased limitations during data transfer as well as generating requests for 

when the server and receivers are connected through long retransmission. All receivers are offered a chance to become 

delay satellite links. Satellite links have transmission delays an active receiver in a controlled manner, and only one 

of several seconds. For the random delay NACK suppres- lO receiver can be an active receiver at any given time. This 

sion scheme to work, receivers have to delay with time process continues until there are no receivers in the group 

intervals longer than the combined transmission delay of the with any missing segments. The second task of the protocol 

up and down links to the satellite. provides synchronization of the file version to ensure that all 

Another drawback of existing muhicast protocols is that receivershave^iheja ^ v crsion^f the data file, 
they assume that the network supports IP multicast routing. Tfie"inveniive method eliminates the acknowledgment 
In this configuration, it is assumed that all group members I implosion problem associated with multicast transport pro- 
can be addressed by a single multicast group address. Most tocols by making only one receiver responsible for gener- 
of these protocols will not work if the network does not \ ating acknowledgments and also requesting retransmissions. 
support an IP multicast service. Unfortunately, support for IP Mn addition, it provides flow control, avoids duplicate trans- 
multicast is not readily available in most existing network 20 missions and makes effective use of unicast and multicast-^ 
hosts and routers. 'communicatio n^ ^ ' " 

Other problems are presented with existing multicast \ The invented method is especially suitable foFliSvvwksl 

protocols because they assume that the multicast application I where the server and receivers are connected through long 
is the primary application in the network. Since their flow ^ delay media suchjs^^telhte links. None of the earlier \ 

control is mostly modeled on TCP, their approach is to'^^ disclosed mechanisms can work efiBcienlly on satelUte links ^ 

aggressively use most of the bandwidth available on theN as they depend on random time-outs at receivers. Th&^^' 

network. This is-a-reasonable _app_roach_for aji_InternetJike^ current invention is also suita ble for wide area networks j 

^-.^__data_network.^However, it is a poor approach for the Y with low latencies.^ 

^ subscriber oriented networks such as paging or cellular^ InlddifiotTto being independent of topology constraints, 

infrastructure networks. For example, in a commercial wire^- the invented method does not require support of IP multicast 

less data or voice network, a central server may need to^ routing. It can work both in networks that support multicast 

distribute generic network configuration information to a \ routing and in those that do not yet support multicast 

large number of base stations, such as switches and RF ^ routing. 
\ controllers. These networks are subscriber-oriented because j 

\ the main job of the infrastructure is to move packets carrying BRIEF DESCRIPTION OF THE DRAWINGS 



V subscriber data or voice as efficiently as possible. The i r . . ^ , ^ ^ 

> network management activities should n ot exceed a certain / ^h^ !°'*eo.ng aspects and many of the attendant advan- 

\__percenlage.of.the available bandwidth^ '"S" of th.s invention _will become more readily appreciated 

, , . . > , as the same becomes better understood by reference to the 

In addition to proper management of the file distribution, ^ following detailed description, when taken in conjunction 

protocols with multicast transport require all receivers to ^^^^^ ^^^^ accompanying drawings, wherein: 

synchronize at periodic intervals during the data transfer r-.^, ^ . 

phase to ensure reliability. This requirement introduces other ^^^^ ^ }l ^" ^"^f tr^t^^" ^ Pn^r art multicast delivery 

problems such as fate sharing. Here, the data transfer system with IP multicast support; 

progress of all receivers may be restricted to the progress of P'*^'* 2 is an illustration of a pnor art multicast delivery 
the slowest receiver. While this may be a useful requirement system not utilizing IP multicast support; 
for the interactive applications, this is undesirable in many FIG. 3 is an illustration of a simple prior art star topology- 
non-interactive applications where some receivers are con- based network; 

nected with slow links. For example, the ncjde connected to FIG. 4 is an overview of the logic implemented in the file 

a fast Tl link at 1.544 Mbits/sec will be limited by other distribution process; 

nodes connected to a slow 9600 bit/sec rate. For non- pj^ 5 ^ overview of the logic implemented in the 

interactive bulk data transfers, this configuration would be ^^^-^^ ^^^^-^.^ ^^^^^.^^ 

completely unacceptable because one slow receiver would ^. ^ ., , , . r 

virtually stop the progress of the entire network. ' ""'8'''" °^ ^'^''^^ J^'^'''" 

* ... selection process for a tree topology-based network; 

Accordingly, this invention presents a novel multicast file r-ir^ t ■ j- r • i * * i u j 

, . ^ \u^A *«- . ,1 J- » *u * u 11 J * FIG- 7 is a diagram of a simple tree topology-based 

distribution method that can efficiently distribute bulk data ^ , u • j i r. r * • i- * 

r J * i„ u ^ • • -J network having a server and a plurahty of receiving chents; 

from one sender to a large number of receivers in wide area * f j & > 

networks. As opposed to interactive multicast applications, ^ illustrates a model of a tree topology-based nct- 

this method is designed to distribute one large data object to work; 

a large number of receivers. This new protocol can also be PIG. 9 is a detailed logic diagram of the active receiver 

deployed with or without support of IP multicast, and is not selection process for a star topology-based network; 

dependent on the network topology. In addition, this inven- FIG. 10 is a diagram of a small star topology-based 

tion also addresses the problem of file synchronization. network; 



FIG. 11 is a detailed logic diagram of the data distribution 
65 process; 

This invention presents a method that delivers arbitrary FIG. 12 A is a detailed logic diagram of the data relrans- 



SUMMARY OF THE INVENTION 

mention presents a method that delive 
data from a single source node, known as a server, to a large mLssion request process; 
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FIG. 12B is a detailed logic diagram of the data retrans- The methods of the current invention require that the server 

mission request process as the process is run on the data takes cognizance of satellite based transmission. The server 

server; adjusts protocol behavior to accommodate long delay trans- 

FIG. 13 is a detailed logic diagram of the selection mission paths and the broadcast nature of communication, 

process for subsequent active receivers; 5 FIG. 3 shows the resulting star topology in satellite based 

FIG. 14A is a logic diagram of the file synchronization networks. ^ ^ ... ^ 

process- and Group Management for Reliable Transport Protocols 

„^ \ . . ^ . , J. . All multicast applications require a mechanism for group 

jfgi^ ^'^^'^"^ ^he data distribution ^^anagement. A reliable multicast application may have 

procedure for the file synchronization process. ^^^^^^^ -^^^^^^ ^^^^p management. Many multicast 

DETAILED DESCRIPTION OF THE appUcaiions use implicit group management, where sources 

PREFERRED EMBODIMENT ^^"^P^^ a multicast address and receivers join the 

same multicast address to receive data. I ins means that any 

Multicast distribution of data requires the presence of an receiver that joins the group is automatically accepted as a 

underlying multicast delivery system that is capable of 15 member of the group. In this approach, the complete 

forwarding data from the sender to every receiver. There are receiver set is unknown to both the sender and individual 

two common methods to forward multicast packets in the receivers. This approach fits well with the way IP multicast 

data network: true multicast, IP multicast, and simulated works, and also with receiver based state management where 

multicast at the application layer, the sender is not required to keep the state information for 

In an IP multicast, file servers simply send the data 20 individual receivers. The implicit group management also 

packets to the receiving cHents' multicast IP address without removes firora the sender the burden of tracking the join-m 

any advance knowledge of clients in the distribution group. sign-off of receivers.^ ^ 

A multicast IP address is a normal client IP address chosen^^-^^ For^some-applications such-^file distribution, groups 

from a reserved range of "class D" addresses. Utilizing ttus membership may remain fixed throughout the session, and ^ 

configuration, clients simply join the group at the multicast 25 the necessary information about the receiver set may be 

IP address to receive any data sent to the group. Group ( pre-configured at the sender. If new receivers are added, a 

memberships are transparently managed by a Internet Group \ S^^^P management protocol, known as an explicit manage- 

Management Protocol (IGMP) running on hosts and routersf 1"^"* «f ^''^^P membership, may be needed to handle^ 

When IP multicast is available, the network routers create a^^ reliable jom-m and sign-ofif of members. In this case, group 

multicast routing tree so that a single packet is appropriately ^0 membership is monitored, and a new receiver may be 

duplicated and forwarded by the router to all members of the \ required to inform the sender and sometimes other receiver, 

gJ.^^p when it joins or leaves the group. When group membership; 

™„ - , . . 1.- . I 1- . i_ 1 is known to the sender, it is easy for a sender to determine 

FIG. 1 shows a prior art multicast delivery system when \ . n • ^ • jr l cc 

^ . M . , . 1 . 1 J . J \ when all receivers have received the data, and free the buffer. 

IP multicast support IS available in the network. The dotted i j n n »u 

• . /I • 1- . n r 1.- 1 c 35 For example, a sender may poll all the receivers, or may use 

hnes in the figure indicate the now or multicast packets trom j..,.^ ■ .arc • j- r^i. • i 

.1. J ^ • r> ^/*/r Ai*u 1. in (^4heir' sign^aff from the group as indication of their complex 

the sender S 102 to the receivers R 106. Although IP V . f, . u u - • 

, ■ * J r *u • ^ tion. However, when group membership is non- 
multicast has existed for some time, there is very uttle^^fer-, . . . . ' „• i j . ■ j u *u n 
, , . r w . r -I-.- • • . . i c ^ deterministic, It cannot be positively determined whether all 
deployment of IP multicast facilities in inter-networks for . ui « • i.- i .u- 

^ . J,, r.u- J- 1 ' receivers were able to receive the multicast data. In this case, 

reasons beyond the scope of this disclosure. ^ „ i * „ • j * r i • i r.- 

^ 40 the sender must maintain the data for a long period of time 

Alternatively, simulated multicast must be used when true ^^^^^ ^ .^ceiver to update itself if it missed the multicast 

multicast routing support is not available. If the underlymg distribution session. The following methods address these 

infrastructure does not support true multicast, it is presumed^ issues of involying_thejmnagement of group membership/ 

a multicast tree would be created before the start of the Method Overview 

multicast file distribution by a mechanism outside the scope ^5 m^ihod of the present invention is caUed the multi- 

of this protocol. A simple method is to configure manually ^asl file distribution and synchronization protocol (FDSP). 

a neighbor-forwarding list for the forwarding multicast j^^^hod is a receiver-initiated protocol in which each 

traffic at each receiver. This information can also be distrib- receiver, a FDSP client, is responsible for ensuring reliable 

uted to each receiver by network management tools and delivery of the complete data from the source, the FDSP 

protocols. FIG. 2 is an illustration of a prior art muhicast 50 ^^ver. This novel method combines both negative and 

delivery system when IP multicast support is not available positive acknowledgment from the receivers, 

by the network. The dotted lines indicate the flow of ^s shown in FIG, 4, the FDSP file distribution process 

multicast packets from the sender S 202 to the receivers R ^j^^ts at box 401 where the FDSP server selects one 

FDSP client as the active receiver. The active receiver 

Delivery of muhicast traffic is affected by the network 55 selection process is explained in further detail in the descrip- 

topology. The two common topologies include the tree and tion of FIGS. 5, 6 and 9. After selecting the active receiver, 

the star based-topology. In the tree topology, the multicast the logic continues in box 402 where FDSP server begins a 

delivery system forms a multicast tree connecting the sender muhicast transmission of the data file. During the file 

and the receivers, with the senders as the root node and the distribution of box 402, the active receiver is responsible for 

receivers as the leaf nodes. Data generated by the sender go controlling the data rate of the multicast transmission. This 

flows through the multicast tree, traversing each tree edge unique flow control mechanism provides feedback to the 

exactly once. If the network supports true multicast, the FDSPserver so the file transmission rate does not exceed the 

multicast routing tree at the routers is automatically optimal Jransmission.rate.of_the_network.—~ 

reconfigured, whenever receivers join or leave a multicas^ At the conclusion of the multicast transmission, thelogic 

group. ^ 65 continues to box 403 where active receiver generates nega- 

If a satellite is used as the communication hub, the live and positive acknowledgments to request relransmis- 

configuration of the network results in a star based-topologyA sion of data packets lost in the first data transmissioff^nljTj 

M ^ 
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one^FDSP-client is-designated as-the active-receiver at any closest device to the FDSP server. The objective of this 

given tinne and thus it is the only FDSP client that is allowedji process is to select the FDSP client with the shortest delay 

to request retransmission of lost data packets from the FDSPr since this node is in the best position to provide quick 

server. Next, in box 404, the FDSP server responds to the >^ feedback _to the receiver durin gihe_da ta transfer phascTTHcl 

^ retransmission requests by re-lransmitting the missing data., 5 process then proceeds to box 504 when the FDSP server J 

V segments to the active receiver. In this stage of the process,\\ sends a Token Grant message to the active receiver. This 

the FDSP server may retransmit the data packets in unicast\ rnotifies that FDSP client tha | it has ^een selected as the ] 
or multicast transmission. A multicast transmission is advanr^ Lactive_receiv,£rjrhe selectiorTproce^therrafter-box'SOS, 

tageous at this stage because all other FDSP clients are also where the active receiver sends a Token Grant confirmation 

set to receive data segments that they have not receivedr^io back to the FDSP server. 

Once the active receiver obtains all of the file data I The active receiver selection process 500 can be carried 

segments, the logic continues to box 405 where the FDSP J out in two different ways depending on the topology of the 

server determines if there are any other FDSP clients with ) network. One embodiment involves a process to select an 

incomplete data files. If the FDSP server finds that there are] active receiver in a tree topology-based network and second 

more FDSP clients with incomplete data files, the process 15 embodiment involves a process to select an active receiver 

\ continues at box 406 wherejhcJDSP^eryer.selectS-a jiew> in a star topology-based network. 

\c tive receiver.^ From this point, the next active receiver can FIG. 6 is a logic diagram of the first embodiment of the 

request data segments that it has not received. The process selection process, the selection process for a tree topology- 

of boxes 403-406 continues until all FDSP clients receive all based network 600. The diagram in FIG. 6 is described 

of the data segments from the data file transmitted in box 20 below as the logic is applied to the network 710 in FIG. 7. 

402, When all FDSP clients have the complete data file the In this embodiment, the FDSP server 720 controls the 

process terminates until the next data file is sent from the number of FDSP clients 722, 724, 726, and 728 that will 

FDSP server. This process is carried out each time the FDSP receive the Open Token message 738 by adjusting the value 

server needs to transmit a data file to multiple clients, of the Time-to-Live (TTL) field in the IP header of the 

FDSP uses several messages during the operation illus- 25 packet. As known in the art, the TI'L value in an IP header 

trated in FIG. 4. Messages from the FDSP server are sent determines the length of time that particular packet transmits 

using both multicast and unicast distribution. Messages from through a network. Once the time period set in the TTL field 

FDSP clients are sent to the FDSP server using unicast only. expires for that individual packet, the transmission of that 

FDSP uses two types of messages: data packets and control particular packet terminates. The use of the TTL field is one 

packets. Data packets carry actual data segments of the data 30 method of selecting a smaller subset of clients out of the 

file from the FDSP server. Control packets perform a variety entire client group. As shown in box 602, it is preferred that 

of operations and are generated by the FDSP server as well the first Open Token message 738 is sent with the TTL value 

as by FDSP clients. Some functions that require use of of 1. After the TTL value is set, the FDSP server 720 sends 

control packets include requests for retransmission, selec- the first Open Token message 738, as shown in box 604. 
tion of an active receiver and FDSP file synchronization. 35 The process then proceeds to box 606 where the FDSP 

The following sections explain each box of FIG. 4 in clients 722, 724, 726, and 728 respond to the Open Token 

further detail. In each summary it is assumed that all packets message 738 by transmitting a Token Request messages 740, 

have a unique sequence identifier. In addition, it is to be 742, and 744 back to the FDSP server 720. FDSP clients 

assumed that the FDSP server ignores all duplicate control 722, 724, 726, and 728 respond to the Open Token message 

messages sent by the active receiver Similarly, all FDSP 40 738 only if they are missing data segments. The logic then 

clients ignore duplicate control or data packets from the continues to decision box 608 where the FDSP server 720 

FDSP server. determines if it has received at least one Token Request 

Selection of Active Receiver message within a time-out period. In the preferred 

As shown in box 401 of FIG. 4, the FDSP process starts embodiment, the time-out period is predetermined and can 

when the FDSP server selects an active receiver. The process 45 be for a tree based network, for example, equal to: 0,2 

of box 401 is explained in further detail in FIG. 5, a logic seconds+TTL Count*0.1 seconds. Thus, for a TTL Count of 

diag ram ^ fthe active receiver selection pr ocess 50 0. 1, the time-out period is 0.3 seconds. In general, all timers 

The selection^rocess"begins"at"box 501 with a^imple> should be doubled at the next try to avoid the response from 

token granting mechanism to select one of the FDSP clients] being delayed due to temporary congestion in the network, 

as the active receiver. In step 501, the FDSP server multi^ 50 In addition, the timer values are configurable and adjusted 

casts an Open Token message directed to a subset of FDSP for the network topologies and link speeds, 
clients, llie Open Token should be transmitted to a limited"^ If the FDSP server 720 does not receive a response, the 

group of clients, where the entire group of clients is divid^dj logic continues to box 610 where the FDSP server 720 

into several logical subsets. This limitation allows only o"ne^ increases the TI L value before the Open Token message 738 

subset of FDSP clients to respond to an Open Token mes- 55 is resent in box 604. In box 610, the TTL value is should be 

sage. It is suggested that each subset of FDSP clients consist J increased by 1 but this value could be incremented by any 

of a small number of receivers, e.g. less than 20. Detailed ^ other number depending on the network topology and the 

descriptions of the methods for dividing the FDSP client pJ depth of the tree. The logic in boxes 604-610 repeats until 

group into smaller^ubscts are included in the description of:^ the FDSP server 720 receives at least one Token Request 

FIGS. 6, and -9. J — . _ j message from a FDSP client or until the TTL reaches a given 

Next, in box 502, all FDSP clients that receive the Open maximum value. 
Token message respond with a Token Request message. When the FDSP server 720 receives at least one respond- 
When the FDSP server receives the client Token Request ing FDSP client at decision box 608, the logic continues to 
messages from the responding FDSP clients, the logic box 612 where the FDSP server 720 determines if the 
proceeds to box 503 where the FDSP server selects the first 65 number of responding FDSP clients is too high. A suggested 
responding FDSP client as the active receiver. ITie first above, the scope of the broadcast should reduce the number 
responding FDSP client is selected as it is deemed to be the of receiving FDSP clients to approximately twenty. If the 
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FDSP server 720 finds that there are too many responding by measuring the delay between sending the Token Request 

FDSP clients, the logic continues to box 614 where the message 740 and receiving the Token Grant message 746 

FDSP server reduces the scope of the Open Token message from the FDSP server. The recommended value for the time 

738, thereby reducing the number of recipients, before the limit, T2, is two limes the RTT from the FDSP server 720 to 

Open Token message 738 before it is resent in box 604. The 5 the active receiver 722. 

mechanism for reducing the number of receiving FDSP FIG. 8 illustrates another model of a tree topology-based 

clients is further explained below in the description of the network. This model divides the network into a plurality of 

logic diagram in FIG. 9. This mechanism allows the FDSP concentric circles 803-805 with a fixed center node as the 

server to reduce the number of receiving FDSP clients that FDSP server 801. Each circle defines a boundary, or scope, 

are the same TTL length from the FDSP server by the use of 10 of a transmission and the TTL value is used in the selection 

a base number and a matching number in the Open Token process to control the scope of the broadcast. Each time the 

message. TTL value is increased, the FDSP server 801 increases the 

If the FDSP server 720 does not detect loo many FDSP number of receiving FDSP clients 802 by allowing the 

client responses in box 612, the logic continues to box 616 packet to transmit to the outer circles 804 and 805. This 

where the FDSP server 720 selects the first responding FDSP is expandable scope control is inherently robust because any 

client as the active receiver. In FIG. 7, the first responding receiving node 802 that fails to receive an Open Token 

FDSP client is "Client 1" 722, thus it is now the active message during one transmission has another opportunity to 

receiver. The logic then proceeds to box 618 where the receive the message during the next transmission after the 

FDSP server 720 notifies the active receiver 722 of its TTL value has increased. 

selection by transmitting a Token Grant message 746 back 20 If the network does not support true IP multicast, the 

to the active receiver 722. When the Token Grant 746 FDSP server maintains the TTL value in the Open Token 

message is sent, the FDSP server 720 also starts a timer with packet itself (instead of relying on the TTL value in the iP 

a limit of T2. The timer on the FDSP server 720 measures the packet header) to broaden the transmission scope. Instead, 

response time of the active receiver. When the active each intermediate FDSP client decrements the TTL value in 

receiver 722 receives the Token Grant message 746 from the 25 each packet before forwarding the packet to the next node in 
FDSP server 720, it responds by sending a Token Grant ^ — the^distribution t ree. 

Confirmation message 748 back to the FDSP server 720. \ FIG. 9 is a logic diagram of Fhe^econd embodiment~df tKe^ 

Next, at box 622, the FDSP server 720 then determines if selection process, the selection process for a star topology- j 

it has received the active receiver's Token Grant Confinma- based network 900. In this embodiment, the FDSP server| 

tion message 748 within the time limit of T2. If the FDSP 30 controls the number of FDSP clients that will receive the- 

server 720 detects that the active receiver 722 has responded Open Token message by the use of a novel process that- 

within the T2 time limit, the FDSP server 720 terminates ihc^ dynamically changes the number of responding FDSP cli- 

active receiver selection process 600 and prepares to execute ents from the Open Token broadcast, 
the data distribution process depicted in box 402 of FIG. 4\ The selection process for a star topology-based network 

However, if the FDSP server 720 does not receive the '35 900 starts at box 902 whercr the FDSP server designates a 

client Token Grant Confinmation message 748 within the^ base number and a matching number in the packet header of 

time limit of T2, the logic continues to boxes 624, 618, 620 the Open Token message. The Open Token message also 

and back to 622, where the FDSP server 720 repeats the_^ specifies which byte to use for the computation. Therefore, 

Token Grant transmission. 'I'his loop continues until the J as seen below, all receivers will use the same byte from their 

FDSP server 720 receives a Token Grant Confirmation HO IP address for the required computation. Next, in box 904?^ 

message 748 from the active receiver 722 within the T2 time ^ the FDSP server sends the Open Token message via a\ 

limit or until the FDSP server 720 has sent the Token Grant^ multicast transmission to every FDSPchent on the network.^^ 

message 746 to the active receiver more than X times. In this\' Since all FDSP clients receive the Open Token message, / 

type of network, the value for the maximum number of j each FDSP client must execute a mechanism to reduce ihe"^ 

Token Grant messages, X, should be approximately three. If MS number of FDSP clients that respond to the FDSP server], 
it is found at decision box 624 that the FDSP server 720 hasr Boxes 906-914 show the process executed on each FDSI^ 

sent the Token Grant message 746 more than X times, theN^ client to determine if it will respond to the FDSP server. At 

logic proceeds to box 626 where FDSP server 720 generates^ box 906, each FDSP client selects the predetermined byte 

an alarm. At this point, it is assumed that the current active^ from its own IP address dictated by the Open Token mes- 
receiver has failed and the process continues back to box 604^^ sage. Next, in box 908, as the FDSP clients receive the Open\ 
where the FDSP server 720 broadcasts another Open Token_3 Token message, each cfient divides the integer value of its\ 

message to select a different active receiver. { selected byte by the base number in the Open Token \ 

When the FDSP server selects an alternate active receiver,^ message. This division produces a quotient, Q. The logicl^ 

the Open Token message is sent to all FDSP clients with the then continues to box 910 where each FDSP client compares ^ 

same scope as the last successful Open Token message. 55 the quotient, Q, with the matching number injhe Open j 

More specifically, this means that the Open Token message Token message. As shown in box 914, each FDSP client with 

maintains the same TTL value and the same scope param^ a quotient result less than the matching number in the Open\ 

eters as the last successful Open Token message. The Opcn'^ Token message sends a Token Request message back to the ^ 

Token message scope parameters are described below in the FDSP server. Conversely, as shown in box 912, each FDSP } 

description of FIG. 9. / 60 client with a quotient greater than the matching number ] 

The time limit, T^, used in box 622 is calculated from the ^ terminates the selection process until the next Open Token^ 

round trip time (RTT) measured during the selection pro- message is sent from the FDSP server " 
cess. More specifically, the FDSP server measures the timef FIG. 10 depicts a diagram of a srnill^tarhetwork lOOO^ 

duration from the transmission of the Open Token message \ and how the selection process of FIG. 9 is applied to thej 
738 to the receipt oflhe client Token Request 740 to measure 65^ network 1000. In this example, the FDSP server 1002n 

the RTF. Also during the selection process, the active.^ broadcasts an Open Token message 1026 with a base num-\ 

receiver 722 also computes the RTT to the FDSP server 720 ber of 10 and a matching number of 1 . If the FDSP clientsC^ 
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select the fourth byte ofTQ~IPTddress, then only FDSPi active receiver. If the file is being distributed for the first 
clients having a value of 1 to 9 for the fourth-by|e in their \ time, the active receiver requests all segments of the data 

IP address are allowed to respond to the server In this | file. A detailed description of the NACK message format is 
diagram, Client 1 1004 and Client 6 1022 are the only clientsj- explained in the description of box 1206 of FIG. 12. 

to return a Token Request message as Client 1 1004 andt 5 The loss of NACK solicitation is handled in the same way 

Client 6 1022 are the only clients with a 0 of 0, less than the' as the loss of a Token Grant message in boxes 618-626 
matching number of 1. In sum, the base number determines^ shown in FIG. 6, As shown in box 1106 of FIG. 11, if the 
the size of logicaLgroups selected from the entir.^^pool ofj server does not receive a NACK from the active receiver 

FDSP clients: The use of the base number also allows the within a time-out period of T2, the FDSP server resends the 

^DS^ server to select the approximate size of each logicafpo NACK Solicitation message. As shown in boxes 1108-1110, 

group such that each group contains no more than a reasony if the NACK solicitation has been transmitted more than X 

^ able number of receivers. In addition, the matching number times, the FDSP server generates an alarm and terminates 
allows the FDvSP server to dynamically control the scope oF^ the data distribution process 1100. At this point, the process 
the Open Token-broadcast-each-time-the_Open JTokejHsJ returns to box 401 of FIG. 4 where the FDSP server selects 

-tra nsmitted. / 15 another active receiver. 

Returning to FIG. 9, if the FDSP client responds to the However, if the FDSP server receives the NACK from the 

FDSP server in box 914, the logic continues to box 916 active receiver within the time-out period, Tj, the logic 

where the FDSP server determines if it has received at least proceeds to box 1114 where the FDSP server divides the data 

one Token Request message within a fixed time-out period. file into smaller data segments. Here, the FDSP server 

This fixed time-out period T2 can be, for example, about 3 20 should divide the data segments into fixed, equally sized 

seconds. If no FDSP client responds to Open Token segments except for the last data segment. The FDSP server 

message, the process continues to box 918 where the FDSP also marks the last data segment with a End-of-File (EOF) 

server increments the matching number by 1. The Open attribute. The data segments should not be divided into 

Token message is then rebroadcasted in box 904 with the segments larger than 1024 bytes. 

new matching number. 'Ilie process in boxes 904-918 25 Next, in box 1116, the FDSP server assigns all data 

repeats until the FDSP server receives at least one Token segments to sequentially numbered data packets. In this 

Request message from a FDSP client or until the matching stage, the FDSP server maps all of the data packets with the 

number exceeds a designated maximum allowed value. sequence number starting at 0. Then in box 1118, the data 

When the server receives a Token Request message from a segments are distributed by a multicast signal to all FDSP 

FDSP client at box 916, the logic proceeds to box 920 where 30 clients. 

the server selects the first responding FDSP client as the To properly execute the data distribution process all 

active receiver. The selection process concludes after the clients must have enough buffer memory to receive the data 

FDSP server and active receiver exchange token messages to segments in any order and still have the ability to reconstruct 

confirm the selection of the active receiver. The token the data file from all of the data segments. Similarly, it is 

exchange process of box 922 is similar to the process 35 necessary for the FDSP server to keep its data intact as long 

described in boxes 618 through 626 shown in FIG. 6 using as a receiver request is pending to update it. FDSP clients 

the time limit of T2. that do not have a sufiBcient amount of memory to store the 

The scope control method depicted in FIG. 9 can be used incoming data segments should terminate the distribution 

to reduce the number of responding FDSP clients. Here, the process and generate an alarm. 

FDSP server essentially subdivides the logical groups of 40 During the data distribution process, it is assumed that 

FDSP clients by decrementing the matching number in the each data file in the FDSP server has a name or a unique file 

Open Token message if too many FDSP clients respond at identifier that maps that data file to a particular data file in 

box 916. This may be desired when the selection method is all of the receiving clients. In addition, each distributed data 

applied to large star networks. file is identified with a unique version number. The FDSP 

As mentioned above, the scope control method depicted 45 server increases the version number of a file by 1 every time 

in FIG, 9 may be applied to the selection process for a tree the server distributes new data for that particular data file, 

topology-based network 600. This control mechanism is The file version number is reset to zero after the version 

effective for tree networks because it has the ability to number reaches a maximum value, e.g. a maximum value of 

reduce the number of responding FDSP clients even if the 16383 is reset to 0. 

clients are at the same TI L length from the FDSP server. 50 Handling Retransmissions and Node Failures 
Thus, box 614 of FIG. 6 would decrement the matching As shown in FIG. 4, after the FDSP server distributes the 
number in the Open Token message before the multicast data file in box 402, the active receiver requests a re trans- 
transmission in box 604. mission of the data segments not yet received by that FDSP 
Distribution of Data client. The processes of boxes 403 and 404 are explained in 
As shown in FIGS. 4 and 6, after the FDSP server receives 55 further detail in FIG. 12A. FIG. 12 A is a logic diagram of the 
the Token Grant Confirmation message in the selection data retransmission process 1200. 

process, the FDSP server then starts the data distribution The data retransmission process 1200. provides reliable 

process shown in box 402. The process of box 402 is delivery of the data file by selectively re-sending lost data 

explained in further detail in FIG. 11. FIG. 11 is a logic segments after all of the segments have been sent in the data 

diagram of the data distribution process 1100. 60 distribution process 1100. The data retransmission process 

The data distribution process 1100 starts in box 1102 1200 uses NACK solicitation messages and NACK mes- 

when the FDSP server sends a unicast NACK Solicitation sages to control the transmission of the data packets, 

message to prepare the active receiver for data distribution. The data retransmission process 1200 starts at box 1202 

The NACK Solicitation message communicates the file size where the FDSP server sends a NACK solicitation to the 

information to the active receiver. 'ITien in box 1104, the 65 active receiver. This NACK solicitation is only sent after all 

active receiver responds by sending a NACK message to data segments are transmitted in the data distribution process 

request specific segments of the data file required by the 1100. As shown in box 1204, the receipt of the NACK 
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solicitation message triggers the active receiver to determine FDSP also addresses the problem of lost NACK or NACK 

if it missed any data segments during the data distribution solicitation messages during the data retransmission process 

process 1100. If the active receiver detects that it has 1200. FIG. 12B is a logic diagram of the data retransmission 

received all data segments of the file, the process continues process 1200 employing a recovery mechanism 1250 that is 

to box 1210 where the active receiver transmits an unsolic- 5 only executed by the FDSP server. In this procedure, lost 

ited NACK to notify the FDSP server it has completed the NACK messages are handled in the same way as the loss of 

data transmission. At this point, the FDSP server assumes a Token Grant message using a time-out period, 

the token has been released from the active receiver and the The process begins at box 1252 where the FDSP server 

logic continues to box 405 depicted in FIG. 4 where the starts a timer with a time limit of T2- In relation to FIG. 12A, 

FDSP server determines if it needs to select another active lO the timer is started when the NACK solicitation message is 

receiver. sent in box 1202. As shown in box 1254, the FDSP server 

However, at box 1204, if the active receiver detects that waits for a response NACK from the active receiver and 

it has not received all segments of the data file, the logic determines if it has received the NACK within a time limit 

proceeds to box 1206 where the active receiver sends a of T2. 

NACK to the FDSP server. The NACK sent by the active 15 If the FDSP server receives a NACK from the active 

receiver is used to request the retransmission of packets lost receiver within the time limit of Tj, the redistribution 

during the data redistribution process 1200. Here, the process continues the same process as illustrated in FIG. 

NACK's are only sent from the active receiver, as the active 12A. As shown in boxes 1258-1262, the FDSP server 

receiver is not responsible for any retransmission requests re-transmits the lost data packets to the active receiver until 

for other receivers. 20 the FDSP server receives an unsolicited NACK message. At 

The NACK message sent in box 1206 includes a data this point, the FDSP server assumes the token has been 

segment number N and a bitmap B. The segment number N released and the logic continues to box 405 depicted in FIG. 

indicates the number of packets that have been correctly 4 where the FDSP server determines if it needs to select 

received by the active receiver and the bitmap B indicates another active receiver. 

whether specific packets beyond N have been received or 25 However, at box 1254, if the FDSP server does not receive 

lost. Specifically, a 0-bit in the bitmap corresponds to a lost, a NACK from the active receiver within the time limit of T2, 

or incorrectly received, packet and a 1 -bit corresponds to a the process continues to decision box 1256 where the FDSP 

correctly received packet. For example, an NACK with server determines if it has re-transmitted the NACK solici- 

N=500 and B=01101111 means that the receiver has cor- tation more than a maximum, X, times. If the FDSP server 

rectly received all packets up to sequence number 500 and 30 has not transmitted the NACK solicitation message more 

has requested retransmission of packets 501 and 504. than X times, the FDSP server resends the NACK solicita- 

The maximum length of a bitmap in a particular NACK tion to the active receiver using a unicast transmission with 

message depends on the implementation. A bitmap length of an increased timeout period Tj. As shown in box 1257, each 

512 bytes allows a receiver to send a cumulative acknowl- time the FDSP server resends the NACK solicitation, the 

edgment of up to 4096 segments. The active receiver can 35 time limit, T2, is multiplied by a factor of two. Thus, T2 

choose to retransmit its NACK's for requesting retransmis- increases each time the NACK solicitation is resent, 

sion in multiple packets with smaller bitmap fields or in a big If the FDSP server has sent the NACK solicitation X 

packet with a large bitmap field. By this method, an active times, the FDSP server terminates the data retransmission 

receiver can choose the most optimum way to request process 1200. As described above, the process continues 

retransmission by dynamically adjusting the size of the 40 from box 1263 to box 405 depicted in FIG. 4 where the 

bitmap field. FDSP server determines if it needs to select another active 

Returning to FIG. 12 A, the logic continues at box 1208 receiver, 
where the FDSP server processes the data in the NACK sent As explained in the description of FIG. 6, the suggested 
from the active receiver and re-transmits the specified data time-out period, T2, is twice the duration of the RTT time 
packets. The transmission of box 1208 should be a multicast 45 measured in the selection process 600. For the tree topology- 
data transfer as each FDSP client is set to receive data based network, the time-out period in this procedure should 
packets not yet received by that particular FDSP client. The be limited to a reasonable maximum number of seconds. In 
retransmission of the missing data packets continues until all practice, this may be on the order of 4 seconds. The time-out 
data segments of the file are received by the active receiver. period, T2, in the star topology-based network should be 
As shown in box 1210, when the active receiver detects that 50 limited to the initial value of twice the duration of the RTT. 
it has received all of the missing data segments, the active The data retransmission process 1200 allows the active 
receiver sends an unsolicited NACK to the FDSP server. receiver to efficiently retransmit lost data. In addition, this 
Once the active receiver sends the unsolicited NACK that mechanism allows an active receiver to slop the process if 
particular FDSP client ignores all other Open Token mes- there is continual packet loss. If the active receiver does not 
sages and subsequent data retransmissions until the FDSP 55 have the complete file after an attempt to request a 
server transmits a new data file. Also, the active receiver retransmission, that particular FDSP client will again 
does not retransmit any unsohciled messages; so there is no become an active receiver after other FDSP chents request 
impact on the active receiver if the FDSP server fails. for data retransmission. Thus, there will be no impact on the 

The unsolicited NACK sent in box 1210, also known as FDSP server even if the active receiver completely fails, 

a token release message, is essentially a NACK message 60 Selecting Additional Active Receivers 

with the "DONE" Flag raised. When the FDSP server As shown in FIG. 4, once the first active receiver 

receives the unsolicited NACK at box 1212, the FDSP server acknowledges that it has received all segments of the file, the 

terminates the data retransmission process 1200. At this FDSP server searches for subsequent FDSP clients with 

point, the FDSP server assumes the token has been released missing data segments to be selected as the next active 

from the active receiver and the logic continues to box 405 65 receiver. FIG. 13 further describes the process of searching 

depicted in FIG, 4 where the FDSP server determines if it for subsequent active receivers 1300 shown at box 405 of 

needs to select another active receiver. FIG. 4. 
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The process starts in box 1302 where the FDSP server 
broadcasts an Open Token message to the FDSP clients. This 
Open Token message has the same broadcast scope as the 
last Open Token message sent to the previous active 
receiver. Specifically, the Open Token message transmitted 5 
at box 1302 has the same base number and matching number 
as the last Open Token message sent to the previous active 
receiver. Next, in box 1304, FDSP clients receiving the Open 
Token message respond by sending a Token Request mes- 
sage back to the FDSP server. In this step, a FDSP client only lO 
respond with a Token Request message if it is missing at 
least one data packet. 

The process then continues in decision box 1306, where 
the FDSP server determines if it has received a FDSP client 
Token Request message within a time-out period, T^. The 15 
time-out period, T^, is calculated by: 

'/\=Thc initial value of 7'i+2*(thc KVV of the previous active 
receiver), 

If the FDSP server receives at least one FDSP client Token 20 
Request message within the time-out period, T^, the logic 
continues at box 1308 where the FDSP server selects the first 
responding FDSP client as the next active receiver. Next, in 
box 1309, the FDSP server exchange Confirmation Token 
messages with the new active receiver, 'lliis token exchange 25 
is similar to the process described in boxes 618 through 626 
shown in FIG. 6 using the time limit of T2. At this point, the 
process of searching for subsequent active receivers 1300 
terminates. The logic then proceeds back to the data retrans- 
mission process of box 402, as shown in FIG. 4. The initial 30 
value of Ti may be as calculated above. 

However, at decision box 1306, if the FDSP server does 
not receive at least one Token Grant message within the 
time-out period, Tj, the logic continues to box 1310 where 
the FDSP server increases the scope of the Open Token 35 
message. As described above, this part of the process 
involves increasing the number of potential receiving FDSP 
clients by increasing the matching number or the TTL 
attribute in the header of the Open Token message. Before 
the FDSP server transmits the Open Token message with the 40 
broadened scope, the FDSP server determines at box 1312 if 
the scope is at a maximum value. If the scope of the Open 
Token message is not at a maximum value, the Open Token 
message is re-transmitted in box 1302. Thus, the FDSP 
server continually re-transmits the Open Token message 45 
until it has received a Token Request message from a FDSP 
client or until the Open Token message has reached a 
maximum value. The maximum value may be based on the 
maximum depth of the multicast tree. It can be configured 
based upon the network topology information after knowl- 50 
edge of how the network is organized. It can also be 
determined automatically by using the UNIX "Traceroute" 
utility and counting the number of hops. 

At box 1312, if the FDSP server determines that the scope 
of the Open Token message is at a maximum scope, the 55 
FDSP server assumes that all FDSP clients have received all 
segments of the data file and thus terminates the process of 
searching for subsequent active receivers 1300 and ulti- 
mately the server terminates the FDSP process until the 
transmission of the next data file. Since the FDSP clients 60 
ignore the Open Token messages when they have all of the 
data segments, the FDSP server can assume that all FDSP 
clients have the complete file when the FDSP server fails to 
receive an Open Grant message from the FDSP clients. 

^fhe FDSP server may also use other procedures to verify 65 
if all FDSP clients have received all of the data segments. 
For example, if the FDSP server uses explicit group man- 
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agement and knows the total number of receivers, it can 
verify whether all receivers have received the file or not by 
polling FDSP clients that were never selected as an active 
receiver. Alternatively, the FDSP server can use group "join" 
and "sign-off" procedures to verify if each FDSP client has 
received the entire data file. The "join" and "sign-off" 
procedure is advantageous because the sender immediately 
knows the identity of FDSP clients that successfully 
received the distributed file. The join and sign-off procedure 
is detailed in the IGMP protocol. 

FDSP also supports abnormal termination of a muUicast 
distribution session. The FDSP server can suspend the 
multicast distribution at any time by sending a Reset mes- 
sage. Upon the receipt of a Reset message, all FDSP clients 
clean up their protocol state. This means that the server has 
aborted the current distribution and will no longer continue 
with the current data distribution for the time being. This 
also means that the clients should free up the memory used 
by a half -delivered file and should not expect any more data 
to complete the file. The FDSP server sends this message 
only when it is being taken off-line during multicast distri- 
bution. FDSP chents that have the complete file distribution 
ignore this message. 
Limiting Repair Transmissions 

FDSP also includes two novel mechanisms to minimize 
network traffic by reducing the number of multicast trans- 
missions. These two mechanisms are called "backward 
looking"' and "forward looking." 

To implement the backward looking technique, the FDSP 
server maintains a list of all data packets that have been 
previously re -transmitted as a result of the active receivers' 
NACK's. If the FDSP server has previously multicast a 
packet in response to a retransmission request, the FDSP 
server assumes that the packet loss is local to the current 
active receiver and that particular data packet is only 
re-transmitted using a unicast transmission. Thus, each data 
packet is re-transmitted by a multicast transmission only one 
time after a re -transmission request. Each time a subsequent 
active receiver requests a particular data packet, that par- 
ticular data packet is sent using a unicast protocol. If the 
network is using an application level multicast forwarding 
tree, the active receiver requesting a second retransmission 
of a data packet may be advised to multicast this data packet 
to its downstream receivers. 

To implement the forward looking technique, the FDSP 
server maintains a list of FDSP clients that respond to the 
Open Token request sent in the selection process 401, In 
addition to selecting one active receiver, the FDSP server 
selects two or three other FDSP clients from the list and 
sends them a Send NACK Immediate message using a 
unicast transmission. If the FDSP server receives a NACK 
with a bitmap of lost packets from these selected receivers, 
it compares those bitmaps with the bitmap of the active 
receiver. This comparison allows the FDSP server to track 
the packets that were only lost by the active receiver and the 
packets that were also lost by other receivers. This method 
allows the FDSP server assume that each packet loss is a 
local receiver loss unless two or more FDSP clients request 
a retransmission for that particular packet. Network traffic is 
reduced because the FDSP server only re -transmits data 
packets by a multicast transmission when more that one 
client requests that particular packet and all other packets are 
re-transmitted by a unicast transmission. 

In addition to reducing the multicasting transmissions, 
FDSP also reduces the possibility of communication errors 
by controlling the data rate of the file transmission to a 
specified bandwidth. Specifically, the FDSP server uses a 
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rate limiting mechanism to maintain an optimum transfer the group of FDSP clients that were members of the distri- 

rate without exceeding the peak transmission rate of the bution group before the data distribution process 1100. Late 

network. In this mechanism, the active receiver is respon- joiners are also prevented from being selected as active 

siblc for providing feedback of the data transfer during the receivers as each late joiner marks its Token Request mes- 

data distribution process HOC. 5 sages with a Late Joiner Attribute. Each time a late joiner 

In this process, the active receiver keeps track of the requests a data segment it is only updated using unicast data 

number of packets lost, P^^^, over a window of data transmission. In addition, the Token Request messages from 

segments. A suggested value for is approximately 64 a late joiner are only processed if no other FDSP client has 

data segments. After the active receiver obtains the last data sent a Token Request. This ensures that only required 

segment of the Wj window, the active receiver sends a flow lo packets are sent using unicast to late joiners while allowing 

control message to the FDSP server giving the number of them to receive most of their packets using normal muhicast 

lost data segments, P^^p in the last monitoring window. The distribution. 

ratio of lost segments P/^„ divided by the number of data The FDSP server allows each FDSP client to determine if 

segments in transmitted, P^^„^, determines the quantum of it is a late joiner by including a New File Attribute in a small 

rate reduction. The new rate, W„^^, can be adjusted accord- is percentage, e.g. 5%, of the data packets transmitted in the 

ing to the following formula: data distribution process 1100. If a FDSP client does not 

receive any data packets with the New File Attribute, that 

^n<^w''^cu-Q^ta^>fP^^i)*^cur FDSP cUcnt considers itself as a late joiner As described 

wiu • fu * * f 4 ... ; r above, each Token Request sent by a late joiner includes a 

Where W^„^ IS the current rate of transmission m units of _ ^ . , . , , . . ... , 



20 Late Joiner Attribute until a new data file is transmitted. 



i)if(W,„,-W,„,)>=l 



")if(W,„,-W,„>l 



Kbytes per second. t-,^^t^ . • . ^ 

ir ,,,,7 , til -J J • FDSP Synchronization Protocol 

li all W, segments are successfully received during the t i ,• • . , r , r. 

„ , • . . in » 1 In addition to the data transfer and now control 

monitoring window, the active receiver sends a flow control , . , . ^, , . 

message showing a /xro packet loss. The FDSP .server then mechanisms FDSP also uUhzcs a unique file synchroniza- 

computes its new transmission rate, W„,„, using the follow- previously descnbed each data file m the 

■ fonnulas* FDSP server has a name or a unique file identifier that maps 

that data file to a particular data file in all of the receiving 
clients. In addition, each distributed data file Ls identified 

'^w +a(w w ) ^^^^ ^ unique version number. When the FDSP server 

increases the version number of a file by 1 every time the 
30 server distributes new data for that particular data file. The 
FDSP synchronization protocol allows the FDSP server to 

w =w -w ) continually update the file version number with each FDSP 

max cur cUquX whilc the FDSP file distribution process 400 is in 

Here, W^^ is the maximum rate configured in the FDSP progress. 

Server, W^^^, is the rate at which the last rate decrease took 35 FIG. 14A is a flow chart of the file synchronization 

place, W^„^ is the current rate, and a and p are rate process 1400 as the procedure is implemented on a network 

adjustment factors with value between 0 and 1. The value of having one FDSP server connected to a plurality of FDSP 

a controls how fast the server increases the transmission rate clients. The synchronization protocol begins at box 1402 

to gel back to the rale at which the last loss occurred, and the where the FDSP server raullicasts a series of File Sync 

value of p controls the rate increment after crossing over the 40 messages to all FDSP clients with a delay period of T^ 

^last rate. The suggested value for a is 0.5, which means a between each message. The value of T^ is configurable, but 

rapid recovery, and the suggested value for p is 0.1 which in one actual embodiment, is 15 minutes. The File Sync 

translates a slow increment in the data rate. If no maximum messages communicate the version number of the last file 

rate limiting is required, then W^^ can be defined to be a distributed by the FDSP server to each FDSP client, 

very high value. 45 At the same time, as shown in box 1404, each FDSP client 

To maintain efiScient data transfer, if a flow control is configured to receive the File Sync messages, 

messages is delayed, that flow control message should be As shown in box 1406, as each FDSP client receives each 

discarded by the FDSP server without processing. Any flow File Sync message, they each compare the version of its 

control message delayed more than approximately 256 stored file with the file version advertised in File Sync 

transmitted data segments is considered as a delayed mes- 50 message. If a FDSP client does not detect a difference in the 

sage. In addition, a server can optionally solicit for other file version at box 1404, the logic returns to box 1404 where 

flow control information from FDSP clients other than the the FDSP client waits to receive subsequent File Sync 

active receiver. This is done by enabling a few more receiv- messages from the FDSP server. 

ers that responded to an Open Token message in the selec- If a particular FDSP client detects a difference in the file 

tion process 500 using a mechanism similar to token grant- 55 versions at box 1404, that FDSP client carries out the logic 

ing. These receivers are called associate active receivers. in box 1408 where it aborts any currently running distribu- 

The FDSP server can then use the minimum or average rate tion processes repairing an incomplete file from a previous 

recommendation from several receivers to control flow of data distribution session. Next, at box 1410, the FDSP client 

the data distribution. registers a file update request with the FDSP server by 

FDSP also includes a mechanism for managing "late 60 sending a File Update Request message. At this point, the 

joiners," clients that join the group during the multicast data FDSP client starts a timer to check the round response time 

distribution process 1100. Since many receivers may join the of the File Update Request message, 

group during the distribution process, it is important to As shown in box 1412, when the FDSP server receives the 

prevent a Token Request from late joiners to avoid multi- client File Update Request message, the FDSP server 

casting a large number of data segments that the late joiner 65 responds by sending a File Update Acknowledgment mes- 

missed. FDSP addresses the problem of late joiners by sage back to the FDSP client via a unicast transmission, 

making sure the first active receiver is always selected from After the FDSP server receives the first File Update Request 
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message, the FDSP server rejects any duplicate File Update 
Request messages from all FDSP clients. The logic then 
continues at box 1414 where the FDSP client makes a 
determination of whether it has received the File Update 
Acknowledgment message within a time period of T5. 5 
Again, the time limit of T5 is measured from the time the 
FDSP client sent the File Update Request message in box 
1410. The preferred value for T5 is 10 seconds. 

If a particular FDSP client does not receive a File Update 
Acknowledgment message within the T5 time limit, that 10 
FDSP client then makes a determination of whether it has 
transmitted the File Update Request message more than a 
maximum, X, number of times. The preferred value of X is 
three. If the FDSP client determines that it has not trans- 
mitted the File Update Request message more than X times, 15 
the logic proceeds to box 1418 where the FDSP client 
executes a delay mechanism of T5 before another File 
Update Request message is re-transmitted in box 1410, 
However, at box 1416, if the FDSP client determines that it 
has transmitted the File Update Request message more than 20 
X times, the FDSP chent generates an alarm and makes no 
further attempt to solicit a response from the FDSP server 
until it receives a new File Sync message. At this point, the 
logic returns to box 1402 where the FDSP server continues 
to transmit File Sync messages to the FDSP clients. 25 

However, at box 1414, if the FDSP client receives a File 
Update Acknowledgment message from the FDSP server 
within the T5 time hmit, the FDSP starts a file redistribution 
procedure for the FDSP file synchronization process. This 
procedure, shown in box 1422, allows the FDSP server to 3D 
update the FDSP client with the current file version before 
returning to the File Sync message broadcast procedure of 
box 1402, 

A detailed description of the file redistribution procedure 
of box 1422 is illustrated in FIG. 14B. As shown in box 3S 
1452, the FDSP server starts the file redistribution process 
1422 by recording the identification of the FDSP clients that 
have responded with a File Update Request. Here, the FDSP 
server builds a file redistribution list of all responding FDSP 
clients and continues to record the identification of each 40 
responding FDSP client for a time period of Tg. This delay 
allows the FDSP server to wait for other FDSP clients that 
may respond to the File Sync message. The time period of 
Tg starts from the time the FDSP server sent the File Update 
Acknowledgment message in box 1412. The preferred value 45 
of Tg is 2 minutes. 

Next, in box 1454, the FDSP server determines whether 
the number of FDSP clients in the redistribution list is more 
than a muhicast threshold, M^^^^^,, The muUicast threshold, 
^thresh^ is a preset value used to determine how to transfer 50 
the file to the FDSP clients requesting re-synchronization. 
ITie preferred value of M^^^^, is between 6 to 10. 

If the FDSP server determines that the number of FDSP 
clienLs in the redistribution list exceeds M^;,^^^,, the logic 
continues to box 1456 where the FDSP server redistributes 55 
the previous file version is using multicast transmission. For 
example, if the last File Sync message advertised a file 
version of 12, the FDSP server would now redistribute the 
Uth version of that file. As shown in box 1458, as each 
FDSP client receives the multicast transmission of the data 60 
file they compare the file version in the muhicast with the 
file version of their currently stored file. As shown in box 
1460, any FDSP client that contains the previous file version 
ignores the multicast transmission. Conversely, as shown in 
box 1462, any FDSP client that does not contain the same 65 
file distributed in the multicast transmission stores the data 
file in the multicast transmission of box 1456. The procedure 
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used to carry out the multicast transmission in box 1462 is 
identical to the initial file distribution process 400 as shown 
in FIG. 4. 

Otherwise, if the FDSP server determines that the number 
of FDSP clients in the redistribution list does not exceed 
^thnsh^ the logic continues to box 1462 where the FDSP 
server distributes the current file using a unicast transmis- 
sion. All aspects of the unicast update are identical to the 
initial file distribution process 400 as shown in FIG. 4 except 
the file distribution process incorporates a unicast transmis- 
sion instead of a multicast transmission. During this process, 
the FDSP client receiving the new file operates in the same 
manner as the active receiver in the multicast distribution as 
that particular FDSP client also monitors flow control and 
NACK messages. 

The file synchronization process 1400 addresses the prob- 
lem of lost NACK messages during unicast file transfer 1462 
in the same manner as the data distribution process 1100 and 
the retransmission request process 1200 shown in FIGS. 11 
and 12. The value of the time-out period, T2, is calculated in 
the same manner as the data distribution process 1100 and, 
similar to box 1108, the FDSP server limits the NACK 
solicitation transmissions to a maximum of five times. Thus, 
if the FDSP server does not receive a NACK response after 
X attempts, the FDSP server generates an alarm. 
Large Groups and Scalability 

'llie basic approach presented can be expanded to distrib- 
ute a data file to a very large number of receivers. Two basic 
approaches are possible: a "divide and conquer*' or a hier- 
archical approach. In the divide and conquer approach, the 
group of receivers must be divided into several small 
manageable multicast groups. This approach requires cre- 
ation of several smaller sub-distribution trees, where each 
sub-distribution tree is independent of other sub-distribution 
trees. For example, if a network consists of N receivers, the 
set of N receivers is divided into two groups of Nj and N2. 
Here, the FDSP server may distribute the data files to 
receiver set N^ and N2 by one of the two methods depending 
upon the application requirements. The FDSP server may 
distribute the data files to each group separately, at the same 
time or one after another. 

In the second approach, receivers are organized in a 
multi-level hierarchy. This method is characterized by one 
main distribution group and a number of topological local- 
ized subgroups. The subgroups each have their own multi- 
cast address. Each subgroup includes only one member from 
the receivers that is part of the main distribution group that 
first receives the distribution from the original sender. This 
receiver becomes the new sender and it is assigned the 
responsibility of distributing the data file to the sub group 
using the main distribution protocol. 

While the preferred embodiment of the invention has been 
illustrated and described, it will be appreciated that various 
changes can be made therein without departing from the 
spirit and scope of the invention. 

The embodiments of the invention in which an exclusive 
property or privilege is claimed are defined as follows: 

1. A method of providing reliable data transfer in a 
communications network, said communications network 
coupling a plurality of receiving clients and a file server, 
wherein an IP address including a plurality of bytes identi- 
fies each receiving client of said plurality of receiving 
clients, the method comprising the steps of: 

(a) selecting an active receiver from said plurality of 
receiving clients; 

(b) transmitting a data file from said file server to said 
plurahty of receiving clients, wherein said data file 
consists of a plurality of data segments; 
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(c) if said active receiver detects the absence of at least 
one data segment of said plurality of data segments 
after the completion of said transmitting step, said 
active receiver exclusively requests retransmission of 
data segments not received by said active receiver, 
wherein said active receiver communicates to said file 
server by use of a retransmission request; 

(d) responsive to said retransmission request from said 
active receiver, re-transmitting said data segments from 
said file server to said active receiver, wherein said 
re-transmitting step sends said data segments indicated 
by said retransmission request; 

(e) determining if at least one receiving client of said 
plurality of receiving clients detects the absence of at 
least one data segment of said plurality of data seg- 
ments; 

(f) if at least one receiving client of said plurality of 
receiving clients detects the absence of at least one data 
segment of said plurality of data segments, rcselecting 
a succeeding active receiver from said plurality of 
receiving clients; 

(g) determining if said active receiver detects the absence 
of at least one data segment of said plurality of data 
segments; and 

(h) if said succeeding active receiver detects the absence 
of at least one data segment of said plurality of data 
segments, repeating said requesting step (c) through 
said reselecting step (f). 

2. A method as defined in claim 1, wherein said retrans- 
mitting step (d) also includes retransmitting said data seg- 
ments from said file server to said plurality of receiving 
clients using a multicast transmission. 

3. A method as defined in claim 1, wherein said selecting 
step (a) comprises the steps of: 

(i) transmitting a data packet containing an Open Token 
message over said communications network from said 
file server to said plurality of receiving clients, wherein 
said data packet also contains a time-to-live attribute 
that determines the duration of said data packet trans- 
mission through said communications network; 

(ii) responsive to said Open Token message, communi- 
cating a Token Request message from said plurality of 
receiving clients to said file server; 

(iii) at said file server, determining if at least one Token 
Request message is received from said plurality of 
receiving clients; 

(iv) if said file server does not receive said Token Request 
message at determining step (iii), 

increasing said time-to-live attribute in said data 
packet, thereby increasing the duration of said data 
packet transmission; 

repeating said transmitting step (i) through said increas- 
ing step (iv) until at least one Token Request mes- 
sage is received by said file server; and 

(v) responsive to a received Token Request message 
transmitted from any one said receiving client, thereby 
creating a responding receiving client, at said file 
server, selecting one responding receiving client as an 
active receiver 

4. A method as defined in claim 1, wherein said selecting 
step (a) comprises the steps of: 

(i) broadcasting a data packet containing an Open Token 
message over said communications network from said 
file server to said plurality of receiving clients, wherein 
said data packet also contains a base number attribute 
and a matching number attribute; 
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(ii) on each receiving client, a predetermined byte from its 
own said IP address, thereby creating a primary byte; 

(iii) on each said receiving client receiving said Open 
Token message, dividing said primary byte by said base 
number attribute contained in the received Open Token 
message, thereby creating a quotient value on each 
receiving client; 

(iv) on each said receiving client receiving said Open 
Token message, if said quotient value is less than said 
matching number attribute contained in the received 
Open Token message, transmitting a Token Request 
message from said receiving client to said file server; 

(v) at said file server, determining if at least one Token 
Request message is received from said plurality of 
receiving clients; 

(vi) if said file server docs not receive said Token Request 
message at determining step (v), 

increasing said matching number attribute in said data 
packet, thereby increasing the number of said receiv- 
ing clients responsive to said Open Token message; 
repeating said broadcasting step (i) through said 
increasing step (vi) until at least one Token Request 
message is received by said file server; and 
(v) responsive to a received Token Request message 
transmitted from any one said receiving client, thereby 
creating a responding receiving client, at said file 
server, selecting one responding receiving client as an 
active receiver. 
5. A method as defined in claim 1, wherein said selecting 
step (a) comprises the steps of: 

(i) transmitting a data packet containing an Open Token 
message over said communications network from said 
file server to said plurality of receiving clients, wherein 
said data packet also contains a base number attribute, 
a matching number attribute, and a time-to-live 
attribute that determines the duration of said data 
packet transmission through said communications net- 
work; 

(ii) on each receiving client, choosing a predetermined 
byte from its own said IP address, thereby creating a 
primary byte; 

(iii) on each said receiving client receiving said Open 
Token message, dividing said primary byte by said base 
number attribute contained in the received Open Token 
message, thereby creating a quotient value on each 
receiving client; 

(iv) on each said receiving client receiving said Open 
Token message, if said quotient value is less than said 
matching number attribute contained in the received 
Open Token message, transmitting a Token Request 
message from said receiving client to said file server; 

(v) at said file server, determining if at least one Token 
Request message is received from said plurality of 
receiving clients; 

(vi) if said file server does not receive said Token Request 
message at said determining step (v), 

at said file server, increasing said time-to-live attribute 
in said data packet, thereby increasing the duration 
of said data packet transmission; 

repeating said transmitting step (i) through said increas- 
ing step (vi) until at least one Token Request mes- 
sage is received by said file server; 

(vii) if said file server receives more than a predetermined 
number of said Token Request messages at said deter- 
mining step (v). 
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at said file server, decreasing said matching number 
attribute in said data packet, thereby decreasing the 
number of receiving clients responsive to said Open 
Token message; 
repeating said transmitting step (i) through said 
decreasing step (vii) until said file server receives 
less than said predetermined number of said Token 
Request messages at said determining step (v); and 
(viii) responsive to a received Token Request message 
transmitted from said receiving client, thereby creating 
a responding receiving client, at said file server, select- 
ing one responding receiving client as an active 
receiver. 

6. A method as defined in claim 1, wherein said requesting 
step (c) includes the steps of transmitting a retransmission 
request comprising a segment number and a bitmap, wherein 
said segment number identifies a number of consecutively 
received data segments, and wherein said bitmap identifies 
individual data segments received and not received by said 
active receiver 

7. A method as defined in claim 1, wherein said requesting 
step (c) a)mprises the steps of: 

ordering received data segments, wherein said received 

data segments are from said plurality of sequentially 

numbered data segments; 
determining a value for a segment number, wherein said 

segment number is determined to be the highest 

sequence number of data segment consecutively 

received by said active receiver; 
constructing a bitmap, wherein said bitmap comprises a 

series of binary numbers, and wherein said binary 

numbers indicate data segments received and lost by 

said active receiver; and 
transmitting a data packet to said file server, wherein said 

data packet comprises said segment number and said 

bitmap. 

8. A method as defined in claim 1, wherein said reselect- 
ing step (e) comprises the steps of: 

(I) broadcasting a data packet containing an Open Token 
message over said communications network from said 
file server to said plurality of receiving clients, wherein 
said data packet also contains a base number attribute 
and a matching number attribute; 

(II) at said file server, determining if at least one Token 
Request message has been received from said plurality 
of receiving clients within a specified time period; 

(III) if said file server receives said Token Request mes- 
sage at determining step (II) within said specified time 
period, reselecting a subsequent active receiver from 
said pluraUty of receiving clients; 

(IV) if said file server does not receive said Token Request 
message at determining step (II), 

(i) increasing said matching number attribute in said 
data packet, thereby increasing the number of said 
receiving clients responsive to said Open Token 
message; 

(ii) if said matching number is greater than a predeter- 
mined maximum value at said determining step 
(IV)(ii), terminating said reselecting process; and 

(iii) if said matching number is less than said prede- 
termined maximum value at said determining step 
(IV)(ii), repeating said broadcasting step (I) through 
said repeating step (IV)(iii). 

9. A method as defined in claim 1, wherein said reselect- 
ing step (e) includes the steps of: 

(1) transmitting a data packet containing an Open Token 
message over said communications network from said 
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file server to said plurality of receiving clients, wherein 
said data packet also contains a time-to-live attribute 
that determines the duration of said data packet trans- 
mission through said communications network; 

(II) at said file server, determining if at least one Token 
Request message is received from said plurality of 
receiving clients within a predetermined time limit; 

(III) if said file server receives at least one said Token 
Request message at determining step (II) within said 
predetermined time limit, at said file server, selecting 
one responding receiving client as an active receiver; 

(IV) if said file server does not receive said Token Request 
message at determining step (II), 

(i) increasing said time-to-live attribute in said data 
packet, thereby increasing the duration of said data 
packet transmission; 

(ii) if said time-to-live attribute is greater than a pre- 
determined maximum time-to-live value, terminat- 
ing said reselecting process; and 

(iii) if said time -to -live attribute is less than said 
predetermined maximum time-to-live value, repeat- 
ing said transmitting step (I) through said repeating 
step (IV)(iii). 

10. A method of providing reliable file synchronization 
between a file server and a plurality of receiving clients 
coupled by a communications network, said file server 
contains a plurality of data files, each data file of said 
plurality of data files is identified with a sequenced version 
number, and wherein each receiving client may contain a 
data file identified by a version number, comprising the steps 
of: 

(a) at said file server, transmitting a file synchronization 
message to said plurality of receiving clients, wherein 
said file synchronization message communicates a ver- 
sion number of a selected data file of said plurality of 
data files on said file server; 

(b) on each said receiving client receiving said file syn- 
chronization message, if said version number of said 
data file on said receiving client is different from said 
version number communicated in said file synchroni- 
zation message, transmitting a file update request mes- 
sage to said file server, thereby creating a responding 
receiving client; 

(c) on said file server, executing a delay mechanism, 
wherein said delay mechanism allows said file server to 
receive a plurality of said file update request messages 
from a plurality of responding receiving clients for a 
predetermined duration of time; 

(d) responsive to said file update request message, on said 
file server, responding to each said update request 
message by sending a file update acknowledgment 
message to said responding receiving clients; 

(e) after said predetermined duration of time, if said file 
server has received more than a predetermined limit of 
said file update request messages, muhicasting a syn- 
chronization data file from said file server to said 
plurality of receiving clients, wherein said synchroni- 
zation data file is selected from said plurality of data 
files on said file server, and wherein said synchroniza- 
tion data file identified by a version number less than 
said version number of said selected data file; and 

(f) after said predetermined duration of time, if said file 
server has received a number of said file update request 
messages less than or equal to said predetermined limit 
of said file update request messages, unicasting said 
selected data file from said file server to said respond- 
ing receiving clients. 
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11. A method as defined in claim 10, wherein said 
transmitting step (a) also includes transmitting a plurality of 
file synchronization messages to said plurality of receiving 
clients. 

12. A method as defined in claim 10, wherein said 
unicasting step (f) comprises the steps of: 

(a) selecting an active receiver from said responding 
receiving clients; 

(b) transmitting said selected data file from said file server 
to said responding receiving clients by the use of an 
unicast transmission, wherein said selected data file 
consists of a plurality of data segments; 

(c) after the completion of said transmitting step (b), if 
said active receiver detects the absence of at least one 
data segment of said plurality of data segments, at said 
active receiver, requesting retransmission of data seg- 
ments not received by said active receiver, wherein said 
active receiver communicates to said file server by the 
use of a retransmission request; 

(d) responsive to said retransmission request from said 
active receiver, retransmitting said data segments from 
said file server to said active receiver, wherein said 
retransmitting step sends said data segments indicated 
by said retransmission request; 

(e) if at least one said responding receiving client detects 
the absence of at least one data segment of said 
plurality of data segments, reselecting a succeeding 
active receiver from said plurality of responding receiv- 
ing cHenls; and 

(f) if said succeeding active receiver detects the absence 
of at least one data segment of said plurality of data 
segments, repeating said requesting step (c) through 
said reselecting step (e). 

13. A method as defined in claim 10, wherein said 
multicasting step (e) comprises the steps of: 

(a) selecting an active receiver from said responding 
receiving clients; 

(b) transmitting said synchronization data file from said 
file server to said plurality of receiving clients by the 
use of a multicast transmission, wherein said synchro- 
nization data file consists of a plurality of data seg- 
ments; 

(c) if said active receiver detects the absence of at least 
one data segment of said plurality of data segments 
after the completion of said transmitting step (b), at said 
active receiver, requesting retransmission of data seg- 
ments not received by said active receiver, wherein said 
active receiver communicates to said file server by the 
use of a retransmission request; 

(d) responsive to said retransmission request from said 
active receiver, retransmitting said data segments from 
said file server to said active receiver, wherein said 
retransmitting step sends said data segments indicated 
by said retransmission request; 

(e) if at least one said responding receiving client detects 
the absence of at least one data segment of said 
plurality of data segments, reselecting a succeeding 
active receiver from said plurality of responding receiv- 
ing clients; and 

(f) if said succeeding active receiver detects the absence 
of at least one data segment of said plurality of data 
segments, repeating said requesting step (c) through 
said reselecting step (e). 

14. A method as defined in claim 12 or 13, wherein said 
retransmitting step (d) also includes retransmitting said data 
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segments from said file server to said plurality of responding 
receiving clients using a multicast transmission. 

15. A method as defined in claim 12 or 13, wherein said 
selecting step (a) comprises the steps of: 
5 (i) transmitting a data packet containing an Open Token 
message over said communications network from said 
file server to said plurality of receiving clients, wherein 
said data packet also contains a time -to-live attribute 
that determines the duration of said data packet trans- 
it mission through said communications network; 

(ii) responsive to said Open Token message, communi- 
cating a Token Request message from said plurality of 
receiving clients to said file server; 

(iii) at said file server, determining if at least one Token 
Request message is received from said plurality of 
receiving clients; 

(iv) if said file server does not receive said Token Request 
message at determining step (iii), 

20 increasing said time-to-live attribute in said data 
packet, thereby increasing the duration of said data 
packet transmission; 
repeating said transmitting step (i) through said increas- 
ing step (iv) until at least one Token Request mes- 

25 sage is received by said file server; and 

(v) responsive to a received Token Request message 
transmitted from any one said receiving client, at said 
file server, selecting one responding receiving cHent as 
an active receiver. 

30 16. A method as defined in claims 12 or 13, wherein said 
selecting step (a) comprises the steps of: 

(i) broadcasting a data packet containing an Open Token 
message over said communications network from said 
file server to said plurality of receiving clients, wherein 

35 said data packet also contains a base number attribute 
and a matching number attribute; 

(ii) on each receiving client, selecting a predetermined 
byte from its own said IP address, thereby creating a 
primary byte; 

(iii) on each said receiving client receiving said Open 
Token message, dividing said primary byte by said base 
number attribute contained in the received Open Token 
message, thereby creating a quotient value on each 
receiving client; 

45 

(iv) on each said receiving client receiving said Open 
Token message, if said quotient value is less than said 
matching number attribute contained in the received 
Open Token message, transmitting a Token Request 
message from said receiving client to said file server; 

(v) at said file server, determining if at least one Token 
Request message is received from said plurality of 
receiving clients; 

(vi) if said file server does not receive said Token Request 
55 message at determining step (v), 

increasing said matching number attribute in said data 
packet, thereby increasing the number of said receiv- 
ing clients responsive to said Open Token message; 
repeating said broadcasting step (i) through said 
60 increasing step (vi) until at least one Token Request 

message is received by said file server; and 
(v) responsive to a received Token Request message 
transmitted from any one said receiving client, at said 
file server, selecting one responding receiving client as 
65 an active receiver. 

17. A method as defined in claim 12 or 13, wherein said 
selecting step (a) comprises the steps of: 
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(i) transmitting a data packet containing an Open Token 
message over said communications network from said 
file server to said plurality of receiving clients, wherein 
said data packet also contains a base number attribute, 
a matching number attribute, and a time-to-live 
attribute that determines the duration of said data 
packet transmission through said communications net- 
work; 

(ii) on each receiving client, selecting a predetermined 
byte from its own said IP address, thereby creating a 
primary byte; 

(iii) on each said receiving client receiving said Open 
Token message, dividing said primary byte by said base 
number attribute contained in the received Open Token 
message, thereby creating a quotient value on each 
receiving client; 

(iv) on each said receiving client receiving said Open 
Token message, if said quotient value is less than said 
matching number attribute contained in the received 
Open Token message, transmitting a Token Request 
message from said receiving client to said file server; 

(v) at said file server, determining if at least one Token 
Request message is received from said plurality of 
receiving clients; 

(vi) if said file server does not receive said Token Request 
message at said determining step (v), 

at said file server, increasing said time-to-live attribute 
in said data packet, thereby increasing the duration 
of said data packet transmission; 

repeating said transmitting step (i) through said increas- 
ing step (vi) until at least one Token Request mes- 
sage is received by said file server; 

(vii) if said file server receives more than a predetermined 
number of said Token Request messages at said deter- 
mining step (v), 

at said file server, decreasing said matching number 
attribute in said data packet, thereby decreasing the 
number of receiving clients responsive to said Open 
Token message; 

repeating said transmitting step (i) through said 
decreasing step (vii) until said file server receives 
less than said predetermined number of said Token 
Request messages at said determining step (v); and 

(viii) responsive to a received Token Request message 
transmitted from said receiving client, thereby creating 
a responding receiving client, at said file server, select- 
ing one responding receiving client as an active 
receiver. 

18. A method as defined in claim 1, 12, or 13, wherein said 
active receiver provides a feedback communication to said 
file server during said transmitting step (b), and wherein said 
feedback communication allows said file server to control 
the data rate of said transmitting step (b). 

19. A method as defined in claim 1, 12, or 13, further 
comprising the steps of: 

at said file server, recording all said data segments sent in 
said retransmitting step (d), thereby creating a plurality 
of resent data segments; and 

in each repeated occurrence of said retransmitting step 
(d), if said retransmission request indicates a retrans- 
mission of any said resent data segment of said plural- 
ity of resent data segments, unicasting said resent data 
segment to said active receiver. 

20. A method as defined in claim 1, 12, or 13, further 
comprising the steps of: 

on said file server, selecting a subset of receiving clients 
from said plurality of receiving clients; 
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at each receiving client in said subset of receiving clients, 
requesting retransmission of data segments not 
received by each receiving client, wherein each receiv- 
ing client in said subset of receiving clients communi- 
cates to said file server by the use of a retransmission 
request; 

responsive to said retransmission requests from said 
active receiver and said receiving clients in said subset 
of receiving clients, on said file server, determining all 
specific data segments requested from more than one 
receiving client, thereby creating a plurality of specific 
data segments; and 

on said file server, multicasting said plurality of specific 
data segments from said file server to said active 
receiver and said receiving clients in said subset of 
receiving clients. 

21. A method as defined in claim 1, 12, or 13, wherein said 
transmitting step (b) also includes transmitting a new file 
attribute in a small percentage of said plurality of data 
segments, and wherein said reselecting step (e) also includes 
prioritizing said plurality of receiving clients such that 
receiving clients receiving at least one said new file attribute 
are first selected as said succeeding active receivers. 

22. A method as defined in claim 21 wherein said small 
percentage of said plurality of data segments is less than 
10%. 

23. A method of controlling a data rate in a communica- 
tions network coupling a file server to a plurality of receiv- 
ing clients, and an active receiver, comprising the steps of: 

(a) on said file server, transmitting a data file to said 
receiving clients and said active receiver, wherein said 
data file comprises a series of sequentially numbered 
data segments, and wherein said transmitting step is 
carried out at a current data rate; 

(b) on said active receiver, tracking a number of data 
packets not received during said transmitting step (a), 
thereby creating a total number of lost packets, wherein 
tracking step is executed until said file server transmits 
a predetermined number of said sequentially numbered 
data segments; 

(c) on said active receiver, transmitting said total number 
of lost packets to said file server; 

(d) on said file server, if said total number of lost packets 
is greater than zero, calculating a new data rate by the 
following expression: 
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a new value of, W^^^,, a last decreased data rate, 
wherein W^„^ denotes said current rate of transmission, 
wherein P;^, denotes said number of data packets not 

received by said active receiver, and 
wherein P^^^ denotes said predetermined number of said 

sequentially numbered data segments transmitted from 

said file server; 
(e) on said file server, if said total number of lost packets 

is equal to zero, and if the subtraction of said current 

data rate from said last decreased data rate is greater 

than or equal to one, calculating a new data rate by the 

following expression: 

wherein denotes said new data rate, 

wherein W^_^ denotes said current rate of transmission, and 
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wherein W^^, denotes said last decreased data rate, and 
wherein a denotes a first predetermined adjustment fac- 
tor; 

(f) on said file server, if said total number of lost packets 

is equal to zero, and if the subtraction of said current ^ 
data rate from said last decreased data rate is less than 
one, calculating a new data rate by the following 
expression: 

wherein W„^^ denotes said new data rate, 
wherein W^„^ denotes said current rate of transmission, 
wherein denotes a predetermined maximum data 

rate, and 

wherein denotes a second predetermined adjust- 

ment factor; 

(g) on said file server, adjusting said current data rate 
equal to said new data rate, thereby adjusting said data 20 
rate of transmitting step (a); and 
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(h) repeating said tracking step (b) through said adjusting 
step (g), wherein repeating step is repeated until file 
server transmits all data segments of said data file. 

24, A method as defined in claim 23 further including the 
step of: 

on said file server, selecting a subset of receiving clients 
from said plurafity of receiving clients; 

on said receiving clients in said subset, tracking a number 
of data packets not received during said transmitting 
step (a), thereby creating a total number of lost packets 
on each receiving client in said subset, wherein track- 
ing step is executed until said file server transmits a 
predetermined number of said sequentially numbered 
data segments; 

on receiving clients in said subset, transmitting said total 
number of lost packets to said file server; and 

on said file server, calculating a total number of lost 
packets from an average of said total number of lost 
packets received from said active receiver and said 
subset of receiving clients. 

« * )|c ^ :)£ 
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